10074 bug: Auto Scroll Issues on Petitions Clerk Create Case Form (and more) #5382
Conversation
…ally validated rather than causing a 400 error
…nc with error validations, and rename preventAutoScroll to isSubmitting in most places since that is more meaningful/relevant
| petitionPaymentDate: form.petitionPaymentDate || null, | ||
| petitionPaymentMethod: form.petitionPaymentMethod || null, |
There was a problem hiding this comment.
This fixes issue 2 as listed in the PR description by triggering the validation rather than allowing the form to pass and then cause a 400.
| if (isEmpty(errors)) { | ||
| return path.success(); | ||
| } else { | ||
| return path.error({ errors }); | ||
| return path.error({ errors: { contact: errors } }); |
There was a problem hiding this comment.
The way this action was functioning was failing to update the corresponding form (EditPetitionerInformationInternal.tsx) appropriately.
| @@ -15,7 +15,6 @@ export const alertHelper = (get: Get): any => { | |||
|
|
|||
| return { | |||
| messagesDeduped: uniq(alertError.messages).filter(Boolean), | |||
| preventAutoScroll: false, | |||
There was a problem hiding this comment.
This is useless since it is always false.
| @@ -86,6 +86,7 @@ export const setValidationAlertErrorsAction = ({ | |||
| } | |||
| }), | |||
| ), | |||
| scrollToErrorNotification: props.scrollToErrorNotification || false, | |||
There was a problem hiding this comment.
This gives us a way explicitly telling the app when to scroll to the ErrorNotification banner. By default, we don't scroll. To change the default, we can call the above setScrollToErrorNotificationAction.
| @@ -27,8 +27,8 @@ export const submitJudgeActivityReportSequence = showProgressSequenceDecorator([ | |||
| validateJudgeActivityReportSearchAction, | |||
| { | |||
| error: [ | |||
| setAlertErrorAction, | |||
There was a problem hiding this comment.
Throughout, I have removed setAlertErrorAction when it precedes setValidationAlertErrorsAction since the latter overwrites the former. On submissions, I have called setScrollToErrorNotificationsAction. A good portion of this PR is refactoring sequences to follow this pattern.
Mwindo
changed the title
| @@ -534,7 +534,7 @@ export class Case extends JoiValidationEntity { | |||
| mailingDate: JoiValidationConstants.STRING.max(25) | |||
| .when('isPaper', { | |||
| is: true, | |||
| otherwise: joi.allow(null).optional(), | |||
| otherwise: joi.optional().allow(null), | |||
There was a problem hiding this comment.
Just making the order of these consistent in the file.
| @@ -140,4 +141,23 @@ describe('setValidationAlertErrors', () => { | |||
| messages: ['second nested', 'first nested'], | |||
| }); | |||
| }); | |||
|
|
|||
| it('state.alertError sets scrollToErrorNotification appropriately', async () => { | |||
There was a problem hiding this comment.
nit: this doesn't really read like a sentence ("it does x [when y]") the same way our other test cases do.
There was a problem hiding this comment.
You're right--I will update! Thanks :)
…eteDocketEntryQCSequence
…ion with live validation
TL;DR: Fixing
somequite a few form validation bugs/quirks.The goals of this PR:
ErrorNotificationlive to keep it in sync with in-line validations. (The previous behavior hadErrorNotificationonly updating on submissions, not validations.)setAlertErrorActionfollowed bysetValidationAlertErrorsAction).In the future, we will probably move away from the
ErrorNotificationaltogether--similar to how things work with the new petitioner flow--but this at least keeps behavior consistent until then and hopefully will make a refactor easier.An outline of the issues addressed:
ErrorNotificationbanner. (This was the original error of 10074).2. In certain cases on the petitions clerk create case form, the form scrolled weirdly. (This was design debt 10357.)Not fixed!PetitionsPaymentforms, blank Payment Dates and Payment Methods led to 400 errors rather than validation errors. (See video below.)Screen.Recording.2024-09-20.at.1.50.00.PM.mov